Codecov Report

Merging #112 into dev will increase coverage by 1.10%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##              dev     #112      +/-   ##
==========================================
+ Coverage   79.90%   81.00%   +1.10%     
==========================================
  Files          28       29       +1     
  Lines         602      616      +14     
==========================================
+ Hits          481      499      +18     
+ Misses        121      117       -4     

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 518a615...e7c9045. Read the comment docs.

Tagging @CerenB as you are the one who has started using stim files.

I will adap the code to follow the specifications and then we can see how to adapt the code of your experiment to see how we can make everyone happy. 😄

ok! Did you make changes already? Because under this PR there are 2.2K changes apparently. Should I check the saveEventFile.m?

hum... Let me fix that horrendous number of file changes. (I had commited some node.js files before for the checking the markdown stuff...)

OK this should be more bearable to review now. 😉

To explain the changes.

Official BIDS _stim files are more meant to keep track of stimulus that are shown continuously during a scan: imagine a movie shown for the whole duration of a scan.

The stim file must then be a time series with a new entry at regular time interval. That's why the data dictionary for those stim files must have a "sampling frequency" key (will add a comment after this post). (And also why there is a StarTime key).

Another difference with stim file compared to regular events file is that they have no "header" so the header of each column must be stored in the data dictionary.

All of this is for a RAW BIDS dataset, obvisouly you can do whatever you want in your SOURCE data, but ideally you want to make your life easier when converting your SOURCE into RAW.

So IF you want to have the information that you currently put into those stim files in your raw BIDS data, then it might not be the most convenient for you: you would need to add a row (say every second) to say what was going on during your experiment at this time point.

What you can do in your source data is record all the things you were putting in your stim file into a second events file: it should be fairly easy to do and we can make CPP_BIDS do that for you without any further change.

Another possibility for you is to log all the info into a single events file but if I remember you wanted to avoid that because it would mean logging tons of "extra" stuff in there.

Does that make sense? If not let me know and can hop on a video chat to talk about this.

interesting... I am ok with both options that you mentioned:

What you can do in your source data is record all the things you were putting in your stim file into a second events file: it should be fairly easy to do and we can make CPP_BIDS do that for you without any further change.

Another possibility for you is to log all the info into a single events file but if I remember you wanted to avoid that because it would mean logging tons of "extra" stuff in there._

At the end all I do is to look at what you pressed is actually the same count as the target presented throughout the experiment. It does not need to be in RAW folder. So either it could be at the end of _event.tsv with n/a for all the other columns, or in another.second .tsv file. It should be easy to open another .tsv file, I think, no?

So either it could be at the end of _event.tsv with n/a for all the other columns, or in another.second .tsv file. It should be easy to open another .tsv file, I think, no?

yes it should be quite simple to do.

I will try to add an example in the jupyter notebook folder

@CerenB

Here is a quick demo. Let me know if this is good enough or if I should mention something else.

https://github.com/Remi-Gau/CPP_BIDS/blob/remi-update_bids_validation/notebooks/using_2_logfiles.ipynb

Cool! thank you for this.
I think I'm going to opt for skipping some columns with n/a & having 1 event_tsv file.
But out of curiosity, in this way of saving two _event.tsv, do you think it'll pass the BIDS validator? Because for each _event.tsv, it was asking .json and _bold file. With acq_extraInfo field, it won't ask for json and _bold files?

But out of curiosity, in this way of saving two _event.tsv, do you think it'll pass the BIDS validator? Because for each _event.tsv, it was asking .json and _bold file. With acq_extraInfo field, it won't ask for json and _bold files?

Yes you are correct the BIDS validator will not be happy because there will be an events file with no corresponding bold file.

EXCEPT for purely behavioral files where it won't expect a corresponding bold file.

so if you set

cfg.testingDevice = 'pc';

Then the outpute would be saved in the beh folder and the BIDS validator should be fine with this.